=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Date: Di, 20 Jul 1999 17:47:33 From: Moritz Both To: lokma@syncope.de Subject: OdoConnect als Zerberus Ersatz -------------------------------------------------------------------------------- Für lokma Wie wir Zerberus los werden werden Hallo, ich hatte im Winter angekündigt, eine Lösung zu entwickeln, um Zerberus auf Linux-Basis zu ersetzen. Ich habe mir Gedanken gemacht und möchte diese Gedanken vorstellen und bitte um kritische Anmerkungen. 1. Ziel Ziel des Projekts ist es, Zerberus 5.x überflüssig zu machen. Dabei werden einige von Zerberus bisher erbrachte Dienste mit anderer Software fortgeführt, während andere Dienste entfallen und KundInnen nicht mehr angeboten werden können. 2. Dienste 2.1. Dienste, die ersetzt werden Folgende bisher von Zerberus erbrachte Dienste werden weiterhin gebraucht und müssen also irgendwie ersetzt werden: - Entgegennahme von Anrufen mit JANUS und JANUS2 Protokoll; Transferprotokoll ZModem, PackerInnen ZIP2, LHA und NONE. Das schließt das "herholen" der zu sendenden Daten und das "einsortieren" der empfangenen Daten ein. - "Spoolen" von Mail und News - Prearc - MAPS 2.2. Dienste, die entfallen Dies ist nur eine lose Aufzählung aus dem Kopf: Die komplette Userverwaltung; die Online-Oberfläche mit ihrem Basic; das Netcallprotokoll ZCONNECT; die Transferprotokolle XMODEM, HSLINK und BIMODEM; PackerInnen wie ARC, ZOO usw.; das Sysop-Mäusekino; "Prioritäten" und "Gruppen", Pathalias; Online-Datenbestand (Bretter und PM's)... 3. Wie die Dienste ersetzt werden Die Abwicklung der JANUS- und JANUS2-Netcalls fällt in die Zuständigkeit von OdoConnect ( http://www.comlink.apc.org/~moritz/odoconnect.html ). Diese Implementation funktioniert halbwegs, was JANUS betrifft; für JANUS2 muß noch Arbeit hereingesteckt werden. Die zu sendenden Daten sollen beim Anruf schon im ZConnect-Datenformat vorliegen; die empfangenen Daten werden nach dem Anruf in RFC 822/1036 konvertiert und an einen MTA und ein News-System übergeben. Das "Spoolen", also die Aufgaben von ZSpool, werden von den "nativen" Linux Dämonen erledigt, die als Ergänzung OdoConnect Komponenten bekommen. Das heißt, ein MTA stellt Mail an einen JANUS-Point durch OdoConnect zu; News werden analog zu News für UUCP-Systeme gespoolt und in eigenen Dateien vorgehalten. "Prearc" ist bereits Bestandteil von OdoConnect und muß lediglich durchgesehen werden. MAPS ist der kritischste Punkt. MAPS-Kommandos vom Point sollten so gut wie möglich auf entsprechende Kommandos zum News-System umgesetzt werden. Als Steuersoftware für News-Spool kommt GUP zum Einsatz. Eine genauere Spezifikation tut zu gegebener Zeit Not. 4. Plattform Als Plattform für diese Lösung wird Caldera Open Linux, Version 1.3, festgelegt. (Oder etwas anders? Wie weit ist die Evaluation von RedHat?) Als MTA sollen sendmail und exim einsetzbar sein. Als News-System kommt nur INN in Frage. 5. Migration Die Arbeit, die - neben der möglichst fehlerfreien Zuverfügungstellung der Software - am wichtigsten ist, ist die des Migrations-Konzepts. Idealerweise kann man jederzeit zurück. Es wird sich allerdings noch herausstellen müssen, ob der vorgeschlagene Migrationsweg tatsächlich reversibel sein wird. Ich will es versuchen. Technisch gesehen soll zwischen File-Server und Online-Port jeweils als Dienst gesprochen werden, die jeweils auf irgendeinem Rechner laufen. Bei Zerberus waren das alles notwendigerweise getrennte Rechner (wenn man von Experimenten mit OS/2 o.ä. absieht). Unter Linux kann im Prinzip alles auf einem Rechner laufen. Vielerorts wird es notwendig sein, bis zum Jahresende *beides*, also auch den Server, zu wechseln (Novell 3.11 bei Comlink z.B.) So wie ich mir das z.Z. vorstelle, geht es so: A. In einem ersten Schritt sollen Online-Ports erreichbar werden, die auf den normalen Zerberus-Datenbestand zugreifen. Dazu werden Zerberus' File-Locking Mechanismen imitiert. Diese sind ausreichend erforscht und lassen sich auch von Linux aus simulieren. Empfangende Daten werden nach RFC822/1036 konvertiert und vom Linux-System weiterverarbeitet. Daß heißt, an diesem Punkt ist schon das komplette Linux-System funktionsfähig, ohne aber die Verteilung von Mail und News durchzuführen. B. In einem zweiten Schritt wird die Verteilung von Mail und News von Linux übernommen. Dafür muß MAPS funktionieren, und die an JANUS-Points zu sendenden Daten werden in die alten Zerberus-Netcallverzeichnisse im ZConnect-Format "eingespoolt". Zu diesem Zeitpunkt ist eine einmalige Prozedur notwendig, um die am Zerberus-System bekannten Systeme (Points) auch auf dem Linux-Rechner bekannt zu machen. Ab jetzt - bis C. abgeschlossen ist - müssen Änderungen in dieser Konfiguration immer beiden Systemen bekannt gemacht werden und daran muß ein Mensch denken. Damit ist die Umstellung praktisch schon komplett; trozdem können jetzt immer noch Zerberus-Ports online sein (und Netcalls per HSLINK abwickeln oder so). C. Schließlich werden alle Zerberus-Ports abgeschaltet. Der Prearc wird vom Linux-Rechner übernommen. D. Jetzt wird endlich der File Server verlegbar - die Netcall-Daten werden im Hau-Ruck Verfahren auf eine Linux-Partition kopiert. Dort stehen sie anderen Linux-Rechner per NFS, Sysops auch per SMB zu Verfügung. 6. Wer bekommt es? Es gibt natürlich eine gewisse Chance, daß der Jahr-2000-Dämon so zuschlägt, daß plötzlich die Hälfte aller /CL/ Systeme weg sind. Mir ist mangels Teilnahme an den politischen Netzen in Deutschland in der letzten Zeit nicht klar, wie bewußt es den Leuten ist oder was sie tun. Die Frage ist, soll dieses Konzept und vor allem, das fertige Produkt, dem ganzen /CL/ vorgestellt werden oder behalten wir es für uns. Gegen das Weiterverteilen habe ich nichts, aber vielleicht kann ja eine Organisation davon profitieren, die es brauchen kann. Immerhin geht es um Leute, die vor ein paar Jahren 500 bis 1000 Mark für ein Mailboxprogramm hatten - und die jetzt eine Lösung für ihre kommenden Probleme bekommen. Moritz